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(54) Token-based document transactions 

(57) A system including any number workstations, 
file servers, printers and other fixed devices coupled in 
a network, and a number of portable devices carried by 
users and coupled to the network by infrared (IR) link. 
Each portable device emulates its user's personal 
satchel for documents: the device is programmed to re- 
ceive transmit and store document or service tokens (to- 
kens). Preferably, the token comprises a plurality of 
components defining a document related entity and a 
property of the entity the token components including 
an operation component designating a document relat- 
ed operation, an address component designating the 
electronic address of a document or system providing a 
document related service, one or more parameter com- 
ponents, each parameter component defining a proper- 
ty of a document or a property of a service to be applied 
to a document, and a security parameter dependent up- 
on the identity of a user associated with a document or 
with a document related service. The tokens are distrib- 
uted from one person to another by transmission of IR 
data packets, and once a network-connected computer, 
printer or multifunction device has received a token via 
IR transceiver associated with it, a search request can 
be derived from th tok n and document r f renc s (e. 
g. WWW URLs) satisfying the token can be obtained via 
a search engine. For each URL obtained, the corre- 
sponding electronic document can b retrieved from a 
repository and displayed or print d. The portable device 



is preferably a handheld or wristwatch computer with a 
graphical display for enabling the user to transfer to- 
kens, and the fixed devices preferably include a scan- 
ner/copier/printer having its own IR transceiver. 
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Des rlption 

The present invention relates to data processing, 
and more particularly relates to the transfer between 
computing devices, and the retrieval by such devices, s 
of document related information. Even more particularly, 
the invention concerns such information retrieval, trans- 
fer and processing using tokens. 

While the use of portable computing devices is be- 
coming more widespread, it is as yet not possible to 
store in such devices the electronic files for all the doc- 
uments that a user may wish to have access to (e.g. due 
to storage capacity limitations), and the transfer of bulk 
documents between such devices, or between one such 
device and a desktop office or home computer may be 
time consuming or otherwise user unfriendly. At the 
same time, there is growth in the provision of electronic 
document repositories and expanding use of document 
transfer via the internet. 

This situation is addressed in EP-A-691,619 (here- 
after "EP'SIQ"), which discloses a system including any 
number workstations, file servers, printers and other 
fixed devices (including multifunction devices) coupled 
in a network, and a number of portable devices (e.g. 
handheld or wristwatch computer) carried by users and 
coupled to the network by infrared (IR) link. Each port- 
able device emulates its user's personal satchel for doc- 
uments: the device is programmed to receive transmit 
and store document references (World Wide Web 
URLs), each of which is associated with an electronic 
document stored in an electronic repository at a site on 
the web. Documents are distributed from one person to 
another by transmission of document URLs, and a doc- 
ument is sent to a printer by beaming that document's 
URL to an IR transceiver associated with that printer. 
Mobile workers away from their offices can make use of 
such a system in order to perform activities dealing with 
electronic and paper documents. These activities in- 
clude printing, scanning, viewing, presenting, request- 
ing, giving and distributing documents, and accessing 
document services. 

A problem is that users of documents who are mo- 
bile, (i.e. away from their office, at remote sites of their 
own company, at sites of other companies, at hotels, 
tc.) have a need to perform various activities related to 
electronic and paper documents. These activities in- 
clude sharing documents with others they meet, printing 
out or faxing their documents, acquiring documents 
from others, acquiring documents by scanning, having 
processing performed by services on their documents 
(e.g. format conversion, OCR of scanned documents, 
language translation). They further have a need to do 
so quickly and easily with minimum disruption to ongo- 
ing higher level activities. 

Small personal devices which can perform compu- 
tation such as mobil phones, pagers, and personal dig- 
ital assistants are increasingly b ing carri d by mobile 
workers all the time. Wireless data communication tech- 



nologies for these devices are becoming widely availa- 
ble (e.g. infrared, short-range radio, and cellular phone 
radio). However, th se modes of communication lack 
the necessary bandwidth for the general movement of 
electronic documents because such docum nts can be 
lengthy, complex, rich in images and hence have large 
data sizes. Systems which make use of fixed link com- 
munication can handle such large data loads quickly but 
they are difficult to connect to at remote sites. This may 
be for both physical reasons (wrong kind of connector, 
no ethernet tap nearby) and for security reasons (no 
login account available at remote site within the same 
company, no IP address, or connecting to local network 
at an other company is prohibited). In order for personal 
devices for mobile users to be easy to carry everywhere, 
they must be small. Hence their ability to carry data and 
power is limited. 

Current approaches to supporting mobile users' 
document needs usually involves either relying on a hu- 
man assistant that can always be reached, taking a full 
computer (e.g. a laptop) or collecting and distributing pa- 
per or floppy disks from a briefcase. 

It would be desirable to have systems and methods 
which support these activities and enable transfer doc- 
uments between people and devices in a manner which 
is simple, quick, and secure. These techniques must 
work within the technology constraints prescribed by 
small limited-power portable devices. 

The present invention provides a method carried 
out in a data processing device including a processor, 
memory, and a user interface, comprising: (a) receiving 
at least one user input, the user input(s) defining at least 
one token component, the token components defining 
a document related entity and a property of the entity, 
the token components including an operation compo- 
nent designating a document related operation, an ad- 
dress component designating the electronic address of 
a document or system providing a document related 
service, one or more parameter components, each pa- 
rameter component defining a property of a document 
or a property of a service to be applied to a document, 
and a security parameter dependent upon the identity 
of a user associated with a document or with a document 
related, and (b) compiling a token, the token including 
the component(s) received in step (a). 

Preferably, prior to step (b), step (a) is repeated a 
plurality of times. 

The data processing device may comprise a porta- 
ble computing device, and step (a) comprises receiving 
user inputs via touchscreen or a keyboard. 

The data processing device may comprise a fixed 
computing device, and step (a) comprises receiving us- 
er inputs via touchscreen, a keyboard, and/or mouse. 

The present invention further provides a method 
carried out in a data processing device including a proc- 
essor, memory, and a user interface, comprising: (d) re- 
ceiving a first user input designating a graphical object 
corresponding to a stored token, the token comprising 
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a plurality of compon nts defining a document related 
entity and a property of the entity, the token compon nts 
including an operation component d signating a docu- 
ment related operation, an address component desig- 
nating th electronic address of a document or system s 
providing a document related service, one or more pa- 
rameter components, each parameter component de- 
fining a property of a document or a property of a service 
to be applied to a document, and a security parameter 
dependent upon the identity of a user associated with a 
document or with a document related service, (e) receiv- 
ing a second user input indicating that the token is to be 
sent to another data processing device, (f) encoding the 
token in a data packet, and (g) transmitting the data 
packet. 

The present invention further provides a method 
carried out in a data processing device including a proc- 
essor, memory, and a user interface, comprising: (h) re- 
ceiving a data packet (i) decoding the data packet to de- 
rive a token, the token comprising a plurality of compo- 
nents defining a document related entrty and a property 
of the entity, the token components including an opera- 
tion component designating a document related opera- 
tion, an address component designating the electronic 
address of a document or system providing a document 
related service, one or more parameter components, 
each parameter component defining a property of a doc- 
ument or a property of a service to be applied to a doc- 
ument, and a security parameter dependent upon the 
identity of a user associated with a document or with a 
document related service, and (j) storing the token de- 
rived in step (i). 

The present invention further provides a method 
carried out in a data processing device including a proc- 
essor, memory, and a user interface, the data process- 
ing device being couple in a network to one or more oth- 
er data processing devices, at least one of the data 
processing devices including means for storing a repos- 
itory of electronic documents, comprising: (k) receiving 
at least one user input designating a token, the token, 
the token comprising a plurality of components defining 
a document related entity and a property of the entity, 
the token components including an operation compo- 
nent designating a document related operation, an ad- 
dress component designating the electronic address of 
a document or system providing a document related 
service, one or more parameter components, each pa- 
rameter component defining a property of a document 
or a property of a service to be applied to a document, 
and a security parameter dependent upon the identity 
of a user associated with a document or with a document 
related service, (I) decoding the token to determine 
therefrom one or more document references, the or 
each document reference corresponding to a document 
within said repository satisfying said feature constraint. 

Preferably, step (k) comprises the pr viously men- 
tioned method. 

Th method may further comprise the step of: (m) 



displaying the or each document ref rence d termined 
in step (I). 

The method may furth r comprise th step of (n) in 
response to a second user input designating one of the 
displayed document references, r trieving th docu- 
ment corresponding to said document reference from 
said repository and, optionally, displaying said docu- 
ment or a portion thereof. 

The method may further comprise the step of: (o) in 
response to a third user input, causing the document 
corresponding to said document reference to be printed. 

The present invention further provides a data 
processing device when suitably programmed for carry- 
ing out the method of any of the preceding claims, the 
device comprising a processor, a memory, and a user 
interface. 

The present invention further provides a data 
processing device comprising: a processor, a memory 
coupled to the processor, and a user interface coupled 
to the processor and to the memory and adapted to be 
operable by a user to generate user inputs, means for 
receiving at least one user input, the user input(s) de- 
fining at least one token components, the token compo- 
nents defining a document related entity and a property 
of the entity, the token components including an opera- 
tion component designating a document related opera- 
tion, an address component designating the electronic 
address of a document or system providing a document 
related service, one or more parameter components, 
each parameter component defining a property of a doc- 
ument or a property of a service to be applied to a doc- 
ument, and a security parameter dependent upon the 
identity of a user associated with a document or with a 
document related, and for compiling a token, the token 
including the received token components. 

The present invention further provides a system for 
accessing or distributing electronic documents, includ- 
ing: a repository of electronic documents, each docu- 
ment having a corresponding document reference, and 
a plurality of objects, at least one of said objects being 
portable or mobile, each object including means for 
communicating with the or each other object and with a 
user interface, and means for receiving, storing and/or 
transmitting a token, the token comprising a plurality of 
components defining a document related entity and a 
property of the entity, the token components including 
an operation component designating a document relat- 
ed operation, an address component designating the 
electronic address of a document or system providing a 
document related service, one or more parameter com- 
ponents, each parameter component defining a proper- 
ty of a document or a property of a service to be applied 
to a document, and a security parameter dependent up- 
on the identity of a user associated with a document or 
with a document related service. 

The present invention further provides a portable 
device for accessing or distributing electronic docu- 
ments, including: means for communicating with fixed 



15 



20 



25 



30 



35 



40 



45 



50 



4 



5 



EP 0 893 759 A2 



6 



or mobile electronic devices and with a user interface, 
at least one of said devic s including means storing a 
repository of I ctronic documents, each document 
having a corresponding document reference, and 
means for receiving, storing and/or transmitting a token, s 
the token comprising a plurality of components defining 
a document related entity and a property of the entity, 
the token components including an operation compo- 
nent designating a document related operation, an ad- 
dress component designating the electronic address of 
a document or system providing a document related 
service, one or more parameter components, each pa- 
rameter component defining a property of a document 
or a property of a service to be applied to a document, 
and a security parameter dependent upon the identity 
of a user associated with a document or with a document 
related service. 

The present invention further provides an appara- 
tus for scanning, copying and/or printing documents, in- 
cluding: means for accessing a repository of electronic 
documents, each electronic document having a corre- 
sponding document reference, means for communicat- 
ing with one or more of a plurality of objects, at least one 
of said objects being portable or mobile, and with a user 
interface, and means for receiving, storing and/or trans- 
mitting a token, the token comprising a plurality of com- 
ponents defining a document related entity and a prop- 
erty of the entity, the token components including an op- 
eration component designating a document related op- 
eration, an address component designating the elec- 
tronic address of a document or system providing a doc- 
ument related service, one or more parameter compo- 
nents, each parameter component defining a property 
of a document or a property of a service to be applied 
to a document, and a security parameter dependent up- 
on the identity of a user associated with a document or 
with a document related service. 

The invention employs "Satchel Document Tokens" 
- a special form of reference to a document or to a doc- 
ument service in portable devices, systems and meth- 
ods for supporting mobile worker's document activities. 
These Satchel Document Tokens are henceforth simply 
referred to as "tokens". 

In accordance with the invention, tokens can be 
stored in small personal portable electronic devices and 
can be transmitted between holders of such devices. 
They can also be transmitted to appropriately equipped 
document devices (printers, scanners, copiers, faxes). 
Tokens contain the information necessary to access 
documents, to invoke a document services with appro- 
priate parameter settings, or to initiate the actions of a 
document device with appropriate parameter settings. 
In addition, the token contains the security information 
which provides safeguards to ensure that unauthorised 
use of the documents or document services that are ref- 
erenced in the tok n is precluded. 

In preferred embodiments, a token contains at least 
the following components. 



Basic Operation. Th token specifies the particular 
operation that is to be p rformed, .g. getting th doc- 
ument or p rforming a s rvice (printing, scanning, fax- 
ing, converting). The action may be identified very ge- 
nerically here, with parameter settings used to identify 
the exact operation more specifically. 

Address of document or document service. The to- 
ken contains the information necessary to find the doc- 
ument or service. The address could consist of the net- 
work address of a server and the file path name of a 
document. A WWW Uniform Resource Locator (URL) is 
an example of a document address, and is used in the 
current Satchel prototype. 

Parameters. The token contains a set of parameter 
settings that may be needed by subsequent services 
that are triggered by transmitting the token to a device. 
Parameters are used to further specify the document or 
document service (e.g. Number of copies to print). 
Some parameters may themselves be tokens. The spe- 
cific types parameters required depends on the partic- 
ular service. 

Visible Name. The token contains a string or icon 
which can be displayed to identify the document or serv- 
ice to which the token refers for the benefit of the user. 

Security Information. The security component of a 
token contains information to support ensuring that only 
the intended use of the token is possible. 

The security information includes a digital signature 
of the information in the token. The digital signature is 
a digest of information in the token and its encryption 
with the document owner's private key This follows well 
known prior cryptographic art relating to public/private 
key cryptography (see US-A-4, 405,829). These signa- 
tures can only be generated by the personal portable 
device since only it has the private key. The signature 
ensures the integrity of the token and attests that the 
token did originate from a known portable device. 

The security information can also include specified 
conditions that will restrict access to a document. For 
example, it may include (1 ) an expiry date beyond which 
access to the document is no longer granted, (2) the 
condition that a payment or certificate for release must 
be associated with the token, and/or (3) a requirement 
that only a given device be used to print the document. 

The security information can include a recipient's 
public key or name to indicate that the returned docu- 
ment be encrypted with the given public key or the 
known public key associated with the recipient's name. 
This ensures that only the intended recipient of the doc- 
ument can make use of the returned document and that 
an intercepted copy of either the encrypted document 
or the token is of no use to anyone other than the in- 
tended recipient. 

More generally, information for supporting fees and 
usage rights such as can be expressed in more complex 
fees and usage rights languages (such as d scribed in 
Steftk, M., "Letting Loose the Light: Igniting Commerce 
in Electronic Publication. In Internet Dreams: Arche- 
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types, Myths, and Metaphors. Edited by Mark Stefik. 
MIT Pr ss, 1 996), may be associated with th tok n. 

Tokens which include security information are pre- 
sented to "secure documents servers". A secure server 
contains a "gatekeeper 0 which verifies signatur s on to- 
kens and examines the specified conditions associated 
with the token and then acts accordingly (e.g. encrypting 
the document with the appropriate key). The public key 
for verifying the signature is obtained through a param- 
eter in the security information which identifies the own- 
r of the document or from a server which stores users' 
public keys. 

The problems mentioned in the opening part of this 
disclosure are overcome by using computing devices, 
systems and methods employing a token based ap- 
proach, as discussed in further detail herein. 

There are set out below numerous disadvantages 
of conventional technology, together with details of how 
the token-based techniques provides advantageous so- 
lutions. 

(i) A laptop is too heavy to carry everywhere all the 
time. Tokens can fit into smaller amount of memory 
which will require less power, allowing the device to 
be even smaller. The smaller a device, the more 
easily it can be carried everywhere. 

(ii) Unanticipated need: If the user has forgotten to 
take the paper document or electronic document, 
he or she cannot give the document. A Satchel user 
can always provide a token for a document. There 
is no longer the burden of having to remember 
which documents to take. 

(iii) Speed: A wireless transfer of a token between 
devices will always require less communication 
time than a wireless transfer of the actual docu- 
ment. This streamlines and speeds up the transfer 
transaction and improves its reliability. The lower 
transmission power requirements contribute to 
keeping the device small. 

(iv) Remote login is awkward: When using a laptop, 
the user attempts to find a means to login remotely 
to his/her home office machine or server to access 
documents. This is awkward and complicated, the 
physical connection devices may be wrong, access 
to the local network may be barred (no local login), 
or dial-up to home office may be expensive and 
slow. This is alleviated by providing the security in- 
formation component in the token. 

(v) Transferring an electronic document from one 
user to another is awkward, since the users must 
have a medium (floppy disks, which may be too 
small) or laptop-laptop network which will be clumsy 
to set up. Also, with tokens, any associated 
processing (e.g. format conversion) of a document 
can be performed when the token is submitted 
("cashed -in ") and anywhere where applications for 
processing are available. 

(vi) Dynamic documents: A token can contain a ref- 



erence to a document whos contents change (e. 
g. a weather forecast). The user can thus give a to- 
ken for "the latest version" of a document. This is 
not possible with a static copy of the document from 

s paper, laptop or floppy. 

(vii) Security improvement: The loss or theft of the 
device doesn't mean documents are immediately 
accessible, only tokens. The secure server can be 
instructed to no longer honour tokens from the de- 

10 vice (analogous to revoking a credit card). In the 
case of using a laptop orf loppy .either the data is 
stolen, orthe user must ensure all data on the laptop 
is encrypted. 

is A further benefit is in the enablement of diverse doc- 
ument-related activities, examples of which are given 
below. 

(i) Tradable services. By encapsulating services in 
20 tokens, they can be passed on and distributed just 

like document tokens. 

(ii) Partially Specified Services: The service may 
only be partially specified in the token. A simple ex- 
ample of a partially specified document service is 

25 one which prints a given document in a particular 
way on a printer (e.g. duplex two-up). The remain- 
ing specification of the service (e.g. the actual print- 
er, the number of copies) may not yet be specified, 
but the token can nonetheless be passed from one 

30 user to another. The recipient can then use it as a 
known, reliable, and easy way of having a specific 
service performed, with their choice of further op- 
tions. 

(iii) Network supplied processing: The burden is on 
35 the token-enabled servers on the network to get the 

desired action performed, not on the limited person- 
al device. By using tokens, neither the data nor the 
application of the document need be locally 
present, eith er on the portable device itself or at any 
40 local server. Service execution and invoking appli- 
cations for particular data formats can be performed 
where the appropriate software is available. 

Embodiments of the invention will now be de- 
45 scribed, by way of example, with reference to the ac- 
companying drawings, in which: 

Figure 1 illustrates schematically a portion of the 
network infrastructure which may be used to imple- 

50 ment embodiments of the invention; 

Figure 2 shows a portable computing device used 
in accordance with an embodiment of the invention; 
Figure 3 illustrates schematically the components 
of a token used in accordance with an embodiment 

55 of the invention, (a) in general form, and (b) the doc- 
ument form; 

Figure 4 is a sch matic flow chart of the steps in 
exchanging tokens in accordance with an embodi- 



6 



9 



EP 0 893 759 A2 



10 



ment of the invention; 

Figure 5 is a schematic diagram of the st ps in- 
volved in the transfer, in accordance with an em- 
bodiment of the invention, of a token between a 
portable computing device and on or more fixed 5 
devices; 

Figure 6 is an illustration of the steps involved, in 
accordance with an embodiment of the invention, in 
decoding the token of Fig. 3, once received; and 
Figure 7 is a schematic flow chart of the steps in- 
volved in carrying out the appropriate action as 
specified in the token as received as in Fig. 6. 

1. System hardware 

It will be appreciated that the present invention may 
be implemented using conventional computer network 
technology, either using a local area network (LAN) or, 
more suitably, a wide area network (WAN). The inven- 
tion has been implemented using conventional web 
browser software (e.g. Netscape) providing cross-plat- 
form communication and document transfer over the in- 
ternet. However, it will be appreciated that the invention 
may be implemented using different system configura- 
tions: see EP'619. It will be appreciated that each fixed 
machine forming part of the network may be a PC run- 
ning Windows™, a Mac running MacOS, or a minicom- 
puter running UNIX, which are well known in the art, or 
any suitable processor-controlled network computer. 
For example, the PC hardware configuration is dis- 
cussed in detail in The Art of Electronics, 2nd Edn, Ch. 
10, P. Horowitz and W. Hill, Cambridge University Press, 
1989. 

As is known, upon request of a user at a first ma- 
chine, a document stored on a second machine may be 
retrieved and sent from the second machine over the 
internet, via any number of intermediate machines to the 
first machine. Also, the document may be retrieved us- 
ing as a unique identifier its World Wide Web URL, as 
discussed in EP'619 and international application WO- 
A- , based on British patent applica- 
tion 9708175.6 (agent's ref. R/97005). Preferably also 
connected to the network are any number of processor- 
controlled printers, scanners, fax machines or multifunc- 
tion devices (capable of scanning, printing, copying and/ 
or faxing, etc.) (not shown), as discussed in EP'619. 
Multifunction devices are discussed in more detail in EP- 
A-741 ,487. Each machine coupled to the network is also 
equipped with appropriate hardware and software, 
which is known in the art, for communication with port- 
able computing devices, such as personal digital assist- 
ants (PDAs), handheld PCs, or pocket or wristwatch 
computers. 

A variant of the infrastructure described in the afore- 
mentioned patent applications, for implementing the 
present invention, is shown in Fig. 1. The p rvasive 
computer network 21 has, as is known, an infrared 
transc iver 22 for ach room, desk, workstation, copier, 



printer etc. , coupled thereto. (For th sake of clarity, on ly 
one transceiv r 22 is illustrated). In addition, however, 
the network 21 is coupled to the conventional t lephone 
network 24 by means of gateway 26, which is known in 
the art. In this way, the portable computing device 2 is 
able to communicate with devices on the network 21 not 
only by IR signals to/from transceivers 22, but also 
(when additionally or alternatively provided with digital 
radio frequency communications hardware (not shown)) 
by RF signals to/from a digital cellular base station 28 
of the telephone network 24. Suitably, the RF commu- 
nications hardware (not shown) complies with the GSM 
digital standard, thereby permitting transmission of dig- 
ital data between the portable device 2 and the base 
station 28, which suitably comprises a GSM receiver/ 
transmitter. 

A preferred form of portable computing device is 
shown in Fig. 2. This device 2 is discussed in more detail 
in EP'619. However, it will be appreciated that the com- 
puting device may be fabricated in a multitude of forms: 
for example, the device 2 may be of any of the forms 
disclosed in European patent application EP-A- 

(attorney's reference D/ 

95594/JDR), corresponding to U.S. application S.N. 
08/ ("Personal storage device for ap- 
plication and data transfer", filed 28 March 1996). In its 
preferred form, each portable computing device 2, and 
each of the fixed machines on the network, is equipped 
for infrared communication and suitably, the data pack- 
ets transmitted between the computing device 2 and the 
fixed machines, and enabling the document(s) to be re- 
trieved, conform to the physical and link layer formats 
(IrLAP) described in the industry standard Infrared Data 
Association (IrDA) specification, version 1.0, which is 
well known in the art. 

The tokens concept described here provides an es- 
sential component of a system solution that addresses 
these needs of the mobile worker (e.g. Satchel; EP 
'619), within the technological constraints described 
above. 

A token contains the small amount of essential in- 
formation which allows the system (token-capable serv- 
er software resident on public networks and private net- 
works) to initiate actions which produce the desired re- 
sult. For example, printing out a document only needs 
a simple interaction: The document's token is selected 
on the user interface of the small device. This token is 
incorporated as a parameter of a token identifying the 
print service. When the latter token is received by the 
server software via a wireless and then a wired connec- 
tion (e.g. an infrared receiver which is tethered to the 
local network), the servers acts on the receipt of the to- 
ken and causes the document to be retrieved, proc- 
essed, and printed. In this way it is only the token that 
is transmitted from the personal portable device via 
wireless means and then it is fixed, wired, communica- 
tions that is then used to move the actual document da- 
ta, appropriately processed, to the end device (a printer 
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in this example). The net effect is that a us r can pro- 
duce a desir d action in a quick and simpl way. 

2. Sat h I T k n - Comp n nts ("packet ncoding n ) 

Figures 3(a) and 3(b) are schematic diagrams of the 
contents of a Satchel Token. They show, abstractly, the 
main components of a Satchel Token. Figure 3(a) is the 
more generalform which specifies the structure of any 
token, whether it is for a service or for a document. Fig- 
ure 3(b) is a simpler version of the same token - one 
which specifies the form of a Satchel Token when the 
token only embodies a straight document request. 

In Figs. 3(a) and 3(b) and the following description, 
text in bold indicates a component which may have fur- 
ther components (e.g. Service Parameters). Boxes and 
lines which are dashed indicate components which may 
be present in some tokens, but need not be present in 
all tokens, i.e. they are not required in order to make a 
valid Satchel Token. 

Referring to Fig. 3(a), the components 
(32,34,342,344,36,38,382-389) of the general form of 
the satchel token 30 are schematically illustrated. 

Al I the compon ents (32 , 34, 342, 344, 36 , 38 , 382-389) 
taken together form a Satchel Token general 30. They 
are stored inside a user's PDA 2 (but they can also be 
stored in user's personal computers/workstations) as 
small packets having the structure indicated in Fig. 3. 
They are taken out of this form and linearised (made into 
a straight linear sequence of ASCII characters) when 
needed. This can be done for two reasons: (i) so that a 
token can be transported through some communica- 
tions medium (wired or wireless) and (ii) so that the to- 
ken as a whole can be taken as a linear sequence of 
ASCII characters for secure hashing and then digital 
signing operations to form the token's digital signature 
component. 

The general token 30 includes a Service Host Iden- 
tifier 32 which identifies a host machine on a network. 
This component indicates to the system where the doc- 
ument or service is available from a host machine on 
the network. Typically this is in the form of a standard 
Internet Fully Qualified Domain Name. 

The Service Host Identifier 32 need not be filled into 
the token 30 by the user's PDA 2. This flexibility is es- 
sential in order to implement the context sensitive capa- 
bilities feature of the Satchel System. This component 
32 of a token 30 may be filled in at a later stage in the 
processing of a token 30. For example, the infra-red 
transceiver device which accepts and conveys tokens 
can fill in the Service Host Identifier 32 - in order to spec- 
ify a Service Host Identifier 32 that is appropriate for that 
transceiver device's location. 

Authorisation - The general token 30 includes a 
component34 which in turn contains the two main secu- 
rity components. It provides the means by which the sys- 
tem can verify that the tok n is g nuine and has not 
be n tampered with. 



The first s curity component is an Authoriser Iden- 
tifier 342 - This component indicates the person that cre- 
ated the token 30. The Authorisation identifier 342 may 
be as simple as an ASCII string of the user's name, or 
be as complex as a full X.509 identity certificate (see 
ITU-T Recommendation X.509 - CCITT document "The 
Directory-Authentication Framework"). The second se- 
curity component is an Authoriser Digital Signature 344, 
which is a string created by the following method: (a) 
linearise all other components in the token to produce 
an ASCII string, (b) produce a hash of the string using 
any suitable well-known secure hash function (e.g. 
MD5, SHA; see Applied Cryptography by Bruce Schnei- 
er, 1 996, John Wiley and Sons), and (c) encrypt the hash 
with the user's private key, which is only kept in the PDA. 
Note that the Authoriser Digital Signature 344 itself is 
not part of the hash, but the Authoriser Identifier 342 is. 

Another component of the general token 30 is the 
Service Identifier 36. The Service Identifier 36 is a com- 
ponent which identifies the particular service (or docu- 
ment) that is to be invoked (or requested) on behalf of 
the user. A feature of the system according to the inven- 
tion is that this Service Identifier 36 may only identify a 
general class of service, with the actual service being 
invoked being deduced by the system from this Service 
Identifier 36 and the additional Service Parameters (dis- 
cussed below) provided. 

The general token 30 includes a further component 
designated Service Parameters 38. This component jt- 
self has several components 382-389 which serve to 
further specify the service request. The Service Param- 
eters 38 includes Service Name 382, which identifies 
how a service is identified to the user as a visible name 
in the user interface of the PDA 2. This may be simply 
a familiar name, e.g. "Print" or "Scan" or "Fax", a graphic 
icon, or can be more complex, e.g. a type-in form to be 
filled in by the user. Also included in Services Parame- 
ters 38 is Satchel Token 384. A Satchel Token 30 can 
itself contain zero or more further Satchel Tokens 
384,389. This is a key aspect of the design of this inven- 
tion in that it allows more complex user requests to be 
created in the form of Satchel Tokens 30 which are com- 
posed of other Satchel Tokens 384,389. This is indicat- 
ed in Fig. 3 by the Satchel Token boxes 384,389. They 
can contain another full token, be it a General Satchel 
Token 30 or simple Document Satchel Token 40. 

The Service Parameters 38 further includes Con- 
text/Location Parameters 386. This component con- 
tains parameters which identify the context in which the 
request is made. The parameters may be filled into the 
token 30 either by the PDA device 2 itself or the wireless 
transceiver devices (infra-red). The location parameters 
386 can include, for example: the type of document de- 
vice (printer, scanner, fax) that the transceiver is at- 
tached to, the local name of the document device, the 
room in which th request was mad , the time when the 
request was mad , the country in which the request was 
made. 
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As shown, as part of the Service Parameters 38, 
Further Service Paramet rs 387 may be included. This 
component contains parameters which can sp city the 
particulars of a request even further. Examples of Fur- 
ther Servic Parameters 387 include: the number of $ 
copies to be printed, the phone number of a fax machine 
that a document is to be faxed to, the name of a scanned 
document. In addition, another component of the Serv- 
ice Parameters 38 may be Further Security Parameters 
388. The use of the token 30 can be restricted, and these 
restrictions supported, by indications in the Further Se- 
curity Parameters component 388. Such additional in- 
formation can include: a cryptographic key to use to en- 
crypt a document when the token is used to request it, 
an expiry date for the validity of the token, a restriction 
on the type or identity of the device that the document 
can be printed on. Additionally, a full specification of the 
digital property rights of the document can be added us- 
ing a statement in a digital property rights language 
(DPRL) (seethe abovementioned M. Stefik reference). 
Since tokens 30 can contain tokens, security restrictions 
that must be satisfied can be associated with tokens at 
each level. 

Referring now to Fig. 3(b), this is a simplification of 
Fig. 3(a), and shows the simpler form of token - a Satch- 
el Token/Document (or "Document Token") 40 - when 
the token is simply a request to access a document. In 
Figs. 3(a) and 3(b) like reference numerals denote like 
elements. 

In the case of the token 40 of Fig. 3(b), the compo- 
nent embodying the Service Identifier 36 is Document 
Identifier 46. This indicates to the system where the doc- 
ument is located. Also, the component embodying the 
Service Host Identifier 32 is the Document Host Identi- 
fier 42. 

Also, for the document token 40, a component des- 
ignated Document Parameters 48 is included. This com- 
ponent itself has several components which serve to fur- 
ther specify the document request. The Document Pa- 
rameters 48 includes a Document Name component 
482, indicating how the document is named for visible 
display in the PDA user interface - i.e. a title, as well as 
satchel token 389 and Further Security Parameters as 
in Fig. 3(a). 

3. Transactions with tokens 

Figure 4 is a schematic flow chart of the steps in 
exchanging a taken (between thePDAs of users A and 
B), in accordance with an embodiment of the invention. 
Initially (step s1) an input is received from user A, re- 
questing the transmission of a token. This request may 
be input by user A via the user interface of the PDA by 
means of button presses, selection from pull down men- 
us, and/or dragging and dropping of icons, as is well 
known in the art (see, e.g. EP '61 9). 

In r sponse to the user request, the PDA of user A 
(hereafter PDA A) transmits (step s2) a qu ry (by wire- 



less, and preferably IR, signals) for the context of user 

A, i.e. for the identification of the users (here: B) of those 
PDAs which are in range of communication. Next, the 
PDA of user B (hereafter PDA B) receives the context 
request query and prepares a response (step s3). Once 
compiled in suitable form, the "Service available" reply 
is sent (step s4) by PDA B. This amounts to saying that 
it is OK to send the token from user A's PDA to that of 
user B. When sending this reply, PDA B can provide a 
user identity or cryptographic key (public) associated 
with the "Service Available" information. 

Once the "Service Available" indication is received 
by PDA A, user A is prompted to make a further selection 
(step s5) via the user interface of PDA A, corresponding 
to the action "Beam Token to User B" - see EP '619). 
Then, at step s6, the necessary components (see Fig. 
3) are assembled and the token (30, 40) constructed. 
This is followed by the wireless transmission of the token 
(i.e. as an I R data packet) (step s7) from PDA A to PDA 

B. Once received (step s8) at PDA B, the newly-arrived 
token is stored in PDA B (step s9) in the conventional 
manner, and this may be with or without further inter- 
vention by user B to place (an icon for) the newly-re- 
ceived token in an appropriate directory. 

Figure 5 is a schematic diagram of the steps in- 
volved in the transfer, in accordance with an embodi- 
ment of the invention of a (print service) token between 
a portable computing device (PDA) and a fixed device 
(printer) in order to accomplish the printing of a docu- 
ment. The top part of Fig. 5 is the same as Fig. 4, except 
that PDA B is replaced by an IR transceiver 22 on the 
network 21 of Fig. 1 : the transceiver 22 may by physi- 
cally attached to (and electronically coupled to) or em- 
bedded in, the printer on which it intended to print the 
document. Also, steps s1' to s8' in Fig. 5 correspond to 
the steps s1 to s8 of Fig. 4, except that the service is a 
"Print Document" service, and the token transmitted is 
a Satchel Print Service token. Parameters (see Fig. 3) 
corresponding to the specific action to perform, in this 
case printing, may be incorporated into the token either 
by the PDA 2 when assembling the token (s6, s6') or by 
the transceiver 22 upon receipt, depending on the cir- 
cumstances. 

In Fig. 5, step s8' is followed by the step (s10) of 
adding parameters to the received satchel/print service) 
token: these may include any of the (components ofthe) 
parameters 38,48 of Fig. 3. Once the parameters have 
been appended to the token, the token is sent over the 
network to workstation 50. 

At workstation 50, upon receiving the token, the first 
step (s11) is to decode the token: this involves checking 
the Authorisation (see Fig. 3), and is described in more 
detail below in connection with Fig. 6. Then, the token 
is analysed at step s13: the substeps constituting the 
procedure of step s13 are described in more detail be- 
low with reference to Fig. 7. An lement of this routine 
is th request for a document held in an electronic re- 
pository - her it is illustrated as being stored on a re- 
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mote file server 52 (which may be in a different building 
or in a different country), although it will b appreciated 
that the document could be stored locally on the work- 
station 50. 

Thus, in order to r quest the document th docu- 
ment token is sent (step s14) to file server 52 where it 
is decoded (step s15) upon receipt, so as to extract the 
Document Identifier 46 (see Fig. 3(b)), e.g. a WWW 
URL Using the Document Identifier 46, the document 
data (electronic file) are retrieved by the file server 52. 
The document data are then sent over the network at 
step s1 7, in the conventional manner, to the workstation 
50 which originally received the Print Service token. 

Once the document data are received at the work- 
station 50, a check is made to see whether the data must 
be converted (to a different format), and if so, the con- 
version is carried out at step s18. For example, printer 
54 associated with transceiver 22 may be capable of 
printing only in Postscript® format; and step s10 there- 
fore included adding parameters to the token designat- 
ing that the data file sent ultimately to the printer must 
be converted to Postscript® format. Following conver- 
sion (if necessary), the (converted) document data are 
sent (step s1 9) to the printer 54. Upon receiving the doc- 
ument data, the document is printed (s20) by the printer 
in the conventional manner. 

Figure 6 shows in detail the substeps of the decode 
Satchel token step of Fig. 5. First the linear ASCII string 
form of the token as received at workstation 50 is rec- 
reated in its structured form, as shown in Fig. 3. Then, 
a test is made at step s124 to see if the Authorisation 
Digital Signature (344; Fig. 3) verifies. If the test is failed, 
an "Authorisation verification failure" message is re- 
turned (step s126), i.e. output to the user in a conven- 
tional manner. 

If success is obtained in the test of step s124, the 
action (service) - here printing a document - is invoked 
by the workstation 50, as described elsewhere. 

Figure 7 shows in detail the substeps involved in 
the Analyse Token step in Fig. 5. Initially, the print serv- 
ice is invoked (step s1 31 ), by virtue of the Service Iden- 
tifier parameter 36 (Fig. 3) designating a print request. 
Then, the Service Parameters 38 (Fig. 3) are examined 
(step s1 32); for example, the printing device which is to 
perform the print (service) may have been specified by 
user (and included as a parameter) prior to transmitting 
the token, or may have been added (step S10; Fig. 5) 
based on context/location parameters 386 (Fig. 3(a)). 
The token may include further service parameters, as 
discussed in Section 2 above. This enables the exact 
print service required (e.g. printer id, number of copies, 
2-sided, etc.) to be deduced (step s1 33). 

Once this has been done, the document to be print- 
ed is requested (step s134), and the document token 
sent to the file server (see Fig. 5). Then, the capabilities 
of the chosen printer are examined (step s1 35): this may 
show that th printer can only print with a certain paper 
size, with only c rtain fonts, or only docum nts in Post- 



script® format, for example. In this way, the conversion 
techniques which need to be performed on the docu- 
m nt data received from the file server (52; Fig. 5) can 
be determined (step s136). Then, once the document 
5 data are sent (s17) to the workstation 50 (Fig. 5), the 
necessary conversion can be carried out (step s1 8) prior 
to despatch of the document to the chosen printer. 



1. A method carried out in a data processing device 
including a processor, memory, and a user inter- 
face, comprising: 

15 

(a) receiving at least one user input, the user 
input(s) defining at least one token component, 
the token components defining a document re- 
lated entity and a property of the entity, the to- 

20 ken components including an operation com- 

ponent designating a document related opera- 
tion, an address component designating the 
electronic address of a document or system 
providing a document related service, one or 

25 more parameter components, each parameter 

component defining a property of a document 
or a property of a service to be applied to a doc- 
ument, and a security parameter dependent 
upon the identity of a user associated with a 

30 document or with a document related, and 

(b) compiling a token, the token including the 
component(s) received in step (a). 

2. A method carried out in a data processing device 
35 including a processor, memory, and a user inter- 
face, comprising: 

(d) receiving a first user input designating a 
graphical object corresponding to a stored to- 
ken, the token comprising a plurality of compo- 
nents defining a document related entity and a 
property of the entity, the token components in- 
cluding an operation component designating a 
document related operation, an address com- 
ponent designating the electronic address of a 
document or system providing a document re- 
lated service, one or more parameter compo- 
nents, each parameter component defining a 
property of a document or a property of a serv- 
ice to be applied to a document, and a security 
parameter dependent upon the identity of a us- 
er associated with a document or with a docu- 
ment related service, 

(e) receiving a second user input indicating that 
the token is to be sent to another data process- 
ing device, 

(f) encoding th token in a data packet, and 

(g) transmitting the data packet. 
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A method carri d out in a data processing device 
including a proc ssor, memory, and a us r inter- 
face, comprising: 

(h) receiving a data pack t 5 

(i) decoding the data packet to derive a token, 
the token comprising a plurality of components 
defining a document related entity and a prop- 
erty of the entity, the token components includ- 
ing an operation component designating a doc- io 
ument related operation, an address compo- 
nent designating the electronic address of a 
document or system providing a document re- 
lated service, one or more parameter compo- 
nents, each parameter component defining a is 
property of a document or a property of a serv- 
ice to be applied to a document, and a security 
parameter dependent upon the identity of a us- 
er associated with a document or with a docu- 
ment related service, and 20 
(j) storing the token derived in step (i). 

A method carried out in a data processing device 
including a processor, memory, and a user inter- 
face, the data processing device being couple in a 2s 
network to one or more other data processing de- 
vices, at least one of the data processing devices 
including means for storing a repository of electron- 
ic documents, comprising: 

30 

(k) receiving at least one user input designating 
a token, the token, the token comprising a plu- 
rality of components defining a document relat- 
ed entity and a property of the entity, the token 
components including an operation component 35 
designating a document related operation, an 
address component designating the electronic 
address of a document or system providing a 
document related service, one or more param- 
eter components, each parameter component *o 
defining a property of a document or a property 
of a service to be applied to a document, and a 
security parameter dependent upon the identity 
of a user associated with a document or with a 
document related service, 46 
(I) decoding the token to determine therefrom 
one or more document references, the or each 
document reference corresponding to a docu- 
ment within said repository satisfying said fea- 
ture constraint. 50 

A data processing device when suitably pro- 
grammed for carrying out the method of any of the 
preceding claims, the device comprising a proces- 
sor, a memory, and a user interface. 55 

A data processing device comprising: 



a processor, 

a memory coupled to th processor, and 
a user int rface coupled to the proc ssor and 
to the memory and adapted to be operable by 
a user to g nerate user inputs, 
means for receiving at least one user input, the 
user input(s) defining at least one token com- 
ponents, the token components defining a doc- 
ument related entity and a property of the entity, 
the token components including an operation 
component designating a document related op- 
eration, an address component designating the 
electronic address of a document or system 
providing a document related service, one or 
more parameter components, each parameter 
component defining a property of a document 
or a property of a service to be applied to a doc- 
ument, and a security parameter dependent 
upon the identity of a user associated with a 
document or with a document related, and for 
compiling a token, the token including the re- 
ceived token components. 

7, A system for accessing or distributing electronic 
documents, including: a repository of electronic 
documents, each document having a correspond- 
ing document reference, and a plurality of objects, 
at least one of said objects being portable or mobile, 
each object including means for communicating 
with the or each other object and with a user inter- 
face, and means for receiving, storing and/or trans- 
mitting a token, the token comprising a plurality of 
components defining a document related entity and 
a property of the entity, the token components in- 
cluding an operation component designating a doc- 
ument related operation, an address component 
designating the electronic address of a document 
or system providing a document related service, 
one or more parameter components, each param- 
eter component defining a property of a document 
or a property of a service to be applied to a docu- 
ment, and a security parameter dependent upon the 
identity of a user associated with a document or with 
a document related service. 

8. A portable device for accessing or distributing elec- 
tronic documents, including: means for communi- 
cating with fixed or mobile electronic devices and 
with a user interface, at least one of said devices 
including means storing a repository of electronic 
documents, each document having a correspond- 
ing document reference, and means for receiving, 
storing and/or transmitting a token, the token com- 
prising a plurality of components defining a docu- 
ment related entity and a property of the entity, the 
token components including an operation compo- 
nent designating a document r lated operation, an 
address component designating the electronic ad- 
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dress of a document or system providing a docu- 
ment related servic , one or more paramet r com- 
ponents, each param ter component defining a 
property of a document or a prop rty of a service to 
be applied to a document, and as curity parameter s 
dependent upon the identity of a user associated 
with a document or with a document related service. 

9. An apparatus for scanning, copying and/or printing 
documents, including: means for accessing a re- 10 
pository of electronic documents, each electronic 
document having a corresponding document refer- 
ence, means for communicating with one or more 
of a plurality of objects, at least one of said objects 
being portable or mobile, and with a user interface, is 
and means for receiving, storing and/or transmitting 
a token, the token comprising a plurality of compo- 
nents defining a document related entity and a prop- 
erty of the entity, the token components including 
an operation component designating a document 20 
related operation, an address component designat- 
ing the electronic address of a document or system 
providing a document related service, one or more 
parameter components, each parameter compo- 
nent defining a property of a document or a property 25 
of a service to be applied to a document, and a se- 
curity parameter dependent upon the identity of a 
user associated with a document or with a docu- 
ment related service. 
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